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(57) Abstract 

A method and system for transacting commerce in a distributed communications system over the Internet comprises the reception and 
transmission of shopping requests, product requests, and payment information between distributed Web sites. The distributed communications 
system comprises: a server system; and a customer system which is coupled to the server system. The server system comprises a virtual 
cashier for receiving product requests and payment information. The virtual cashier responds to a first network address. The server system 
also comprises a virtual store for shopping. The virtual store responds to a second network address. The customer system allows a customer 
to make shopping requests. Java applets and servlets running at distinct network addresses provide much of the functionality. The system 
allows greater efficiencies and lower costs for World Wide Web ("WWW") merchants and for Web site hosting services. 
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A METHOD AND APPARATUS FOR CREATING AN 
ELECTRONIC COMMERCE SYSTEM 

The present invention relates generally to computer networks and more particularly to 
methods and apparatus for providing a scaleable distributed Internet commerce system. 

The World-Wide-Web ("Web") has become immensely popular largely because of the ease 
of finding information and the user-friendliness of today's browsers. A feature known as 
hypertext allows a user to access information from one Web page to another by simply 
pointing (using a pointing device such as a mouse) at the hypertext and clicking. Another 
feature that makes the Web attractive is having the ability to process the information (or 
content) in remote Web pages without the requirement of having a specialised application 
program for each kind of content accessed. Thus, the same content is viewed across 
different platforms. Browser technology has evolved to enable the running of applications 
that manipulate this content across platforms. 

The Web relies on an application protocol called HTML (Hyper-Text Mark Up 
Language), which is an interpretative scripting language, for rendering text, graphics, 
images, audio, real-time video, and other types of content on a Web compliant browser. 
HTML is independent of client operating systems. Therefore, HTML renders the same 
content across a wide variety of software and hardware operating platforms. The software 
platforms include without limitation Windows 3.1, Windows NT, Apple's Copeland and 
Macintosh, and IBM's ATX and OS/2, and HP Unix. Popular compliant Web-Browsers 
include without limitation Microsoft's Internet Explorer, Netscape Navigator, Lynx, and 
Mosaic. HTML interprets links to files, images, sound clips, and other types of content 
through the use of hypertext links. Upon user invocation of a hypertext link to a Web page, 
the browser initiates a network request to receive the desired Web page. 
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The use of electronic commerce on the Web is growing. A variety of traditional larger 
retailers and larger mail order catalogue companies have been offering their goods for sale 
electronically over the Web. Everything from the actual shopping to the determination of 
available inventory and the acceptance of payment is accomplished electronically. The 
merchant's Web site or Web storefront handles all shopping, selection, and acceptance of 
payment transactions automatically. Unlike traditional storefronts, these automatic 
capabilities enable a merchant to have its goods offered for sale twenty four hours a day, 
every day of the year (for an example of a traditional catalogue company with its goods 
available via the Web refer to L.L. BEAN of Freeport, Maine, whose URL is 
www.llbean.com). But the ability to host retail merchandise on the Web is not without 
difficulties. 



It is difficult to integrate the major functions of electronic Web commerce. Three functions, 
in particular, are typically integrated in a retail Web site. The first function is the virtual 
presentation, using text, graphics, or otherwise, of a merchant's products to customers. 
This is sometimes called the "electronic storefront" or "Web storefront," or in the case of a 
catalogue merchant, the "electronic catalogue." The second function is the maintenance of 
inventory, stock, pricing, and availability of each product, as well as tracking sales and 
revenues. The third function is performing the electronic transactions for payment in a 
secure environment, where the collection of a customer's payment information, such as a 
credit card, is performed. Typically, most electronic commerce sites integrate all three of 
these functions at one physical site. 

Companies desiring to do business over the Web face many problems. A first problem is the 
expense and complexity of setting up the necessary elements of an electronic commerce 
server. This difficulty includes: (I) hosting of the Web storefront; (2) maintenance of an 
inventory and financial database; and (3) the roll out of a secured Transaction Server. The 
initial up-front cost is a significant barrier for most small businesses desiring to gain a 
presence on the Web. Therefore, a need exists to lower or even to eliminate the high-cost 
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barrier typically associated with setting up electronic commerce on the Web. The cost not 
only involves software design and implementation, and setting up the necessary equipment, 
but the initial hardware investment capable of running all three elements of an electronic 
commerce server for one business. 

A second problem is meeting the requirement that the Web storefront or Web catalogue be 
constantly up-to-date. Many businesses pay dedicated personnel to update, create, and 
modify their Web sites. The cost of the service to maintain a merchant's Web site can be 
significant. A need exists to provide a merchant with the capability of easily creating, 
modifying, and updating its own Web storefront. 

A third problem is meeting the requirement that the Web storefront inventory and financial 
database must be maintained and updated. Sales, advertised specials, and other changes in 
pricing need to be reflected in the inventory database. For many smaller businesses the 
requirement to keep inventory and financial records electronically, not to mention the 
requirement to be electronically connected to their Web storefront, is too complex and too 
costly. Many smaller businesses use simple written ledgers or standalone software 
applications to control their inventories and finances. For merchants desiring to sell goods 
and services over the Internet, a need exists to be able to have their inventory and finances 
maintained in a scaleable fashion. In this way, as the business grows, the merchant can 
migrate from a pencil and ledger, through a stand-alone electronic database, up to a fully 
connected and automated database. 

A fourth problem is meeting the requirement to automatically accept secure, electronic 
forms of payments. The need to have encryption and clearance software, secure server 
hardware, and secure firewalls makes this requirement expensive. For merchants desiring to 
set up Web storefronts, a need exists to be able to scale electronic payments to meet their 
needs. 
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A fifth problem is achieving the ability to advertise to news groups and other Internet 
text-based users, as opposed to graphics-based users. Popular text-only viewers such as 
Lynx do not have graphical HTML capabilities. A need thus exists for merchants to be able 
to advertise anywhere and to process payment information even in text-only based 
electronic commerce. 



As mentioned earlier, one of the concerns for a merchant desiring to do electronic 
commerce is the Web site development. In the case of a large company that wants to have 
all three functions integrated into one Web site, these costs can easily exceed $1 million. In 
addition, even though the programming will usually not be done by the merchant, the 
merchant will have to devote substantial amounts of time to the layout design and to the 
review. These costs, in time and money, are significant. Smaller companies may opt to 
create their own Web sites. This undertaking can be quite difficult, however, for the 
merchant who is not a sophisticated computer user. While it is relatively easy to create a 
Web site, without competent guidance the site may be poorly designed and therefore of 
little economic value. There is, therefore, a need for a development tool which simplifies 
the design, creation, and maintenance of a Web site for merchants. 

Briefly, in accordance with one aspect of the invention, a method for transacting business in 
a distributed communications system comprises: receiving a shopping request at a virtual 
store from a customer system; and sending a product request to a virtual cashier from the 
virtual store. The distributed communications system comprises: a server system; and a 
customer system which is coupled to the server system. The server system comprises the 
virtual cashier for receiving product requests and payment information. The virtual cashier 
responds to a first network address. The server system also comprises the virtual store for 
shopping. The virtual store responds to a second network address. The customer system 
allows a customer to make shopping requests. 
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Briefly, in accordance with another aspect of the invention, a method for transacting 
business in the distributed communications system comprises: receiving product requests at 
the virtual cashier from the virtual store; and receiving payment information at the virtual 
cashier from the customer system. 

Briefly, in accordance with other aspects of the invention, computer readable media contain 
program instructions for implementing the above methods. 

Briefly, in accordance with other aspects of the invention, virtual stores and virtual cashiers 
implement the above methods. 

FIG. 1 is a functional block diagram of a non-distributed electronic commerce system for 
the World Wide Web ("WWW"), according to the prior art. 

FIG. 2 is a functional block diagram of a distributed electronic commerce system for the 
WWW, according to the present invention. 

FIG. 3 is a functional block diagram of another distributed electronic commerce system for 
the WWW, according to the present invention. 

FIG. 4 is a functional block diagram of another distributed electronic commerce system for 
the WWW, according to the present invention. 

FIG. 5 is a flow diagram of the functions that are performed in a typical shopping 
experience by a WWW customer using the distributed electronic commerce system depicted 
in FIG. 4. 
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1 . Introduction and Overview 

Referring to FIG. 1, there is shown a system 100, according to the prior art, in which the 
three functions of product presentation, database management, and transaction processing 
are contained in one server 108 and are, therefore, not distributed. The server 108 refers to 
a specific computer. These three functions are performed by the Web storefront 106, the 
inventory and financial database 104, and the Transaction Server 102, respectively. An 
example of a provider of this type of non-distributed service is Net.Commerce. It is quite 
possible, however, to distribute the three functions amongst two or more separate servers. 

FIG. 1 also illustrates a functional diagram of a computer network for World Wide Web 
("WWW") access from customers 1 14, 1 16 to the server 108. Access to the server 108 can 
be accomplished directly through a local Internet Service Provider ("ISP") 1 10, or through 
an on-line service provider ("OLSP") 112 such as CompuServe, Prodigy, or America 
Online. 

One method of distributing the electronic commerce functions is to separate out the 
function of the Transaction Server from the Web storefront and the inventory and financial 
database. Referring to FIG. 2, there is shown a system 200 containing a Transaction 
Processor 102 on one server (the Transaction Server 202), and a Web storefront 106 and 
inventory and financial database 104 both on a second server (the Store Server 204). This 
may be desirable, for instance, when the Web merchant desires to maintain its own Web 
storefront, whether due to the merchant's expertise, physical distance from the transaction 
service provider, or otherwise. Such a merchant could use any of the many hosting service 
providers such as CyberGate, Magg.Net, and UUNet. 

FIG. 3 shows a system 300 with a further distribution, in which the database 104 is not 
on-line. The dashed line in FIG. 3 indicates that the inventory and financial system may or 
may not be electrically connected to the server. A computerised system could have an 
electrical interface to the server and not be located on the server itself Alternatively, the 
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inventory and financial system may be stand alone. This may be the case if the Web 
merchant does not have a computerised inventory and financial database system, or if the 
merchant has a computerised database system but simply does not have it connected to the 
server. 

Referring to FIG. 2, the Store Server 204 is a conventional HTTPd (Hyper-Text Transfer 
Protocol daemon). In the preferred embodiment, it is a Sun Microsystems's Java compliant 
HTTPd server running Java compliant supporting standard servlet interfaces such as 
Netscape Java Server software or Lotus Domino Go Java software. By using a Java 
compliant implementation, the same code can run on a variety of operating systems 
supporting the Java Virtual Machine including without limitation Solaris, Unix, ADC, OS/2, 
and Windows 95/NT operating systems. 

As an overview, and referring to FIG. 3, the Transaction Server 202 now does not host the 
Web storefront 106. However, the Transaction Server 202 need not store any of the 
inventory or financial data nor any other information on the product line of the merchant. 
All the information that the Transaction Server 202 needs in order to process a purchase 
(for example, from customer 1 14) is sent to it every time that a purchase is requested. The 
Transaction Server 202 verifies that the customer 1 14 wants to make a purchase of a 
specific "shopping basket" of products and prompts the customer 1 14 for payment 
information. Either the merchant or the Transaction Server 202 can perform the tasks of 
credit card verification, authorisation of the total purchase amount, and funds transfer. 
When the Transaction Server 202 has finished its tasks, it then provides the merchant with a 
status report of the transaction and the customer with a confirmation. 

The Web storefront 106 acts as the virtual store for the customer 1 14, and contains 
whatever information the merchant has built into the Web-site (e.g. pictures, prices, search 
engines, etc.). In the Development Tool Application, there is provided a Development Tool 
for designing the Web storefront 106. This tool greatly simplifies the task of creating the 
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Web storefront initially and of modifying it and updating it. The Tool also ensures that the 
operation with the Transaction Server 202 is seamless for the customer 1 14. 

The Tool derives much of its utility from the fact that it contains a series of templates, 
tailored to different industries, for creating pages. The fields on these templates can be 
filled with text, or with images from clip art (also included with the tool) or can be tailored 
to suit a specific merchant's needs. The task is greatly simplified by the inclusion of a 
prompting mode in which the tool will actually step a user through the process. As an 
additional tailoring feature, the tool can be adapted to whatever "look and feel" the 
customer may desire. The customer may want to match the look and feel to that of other 
applications that the customer uses, or may simply feel more comfortable with another look 
and feel. 

In the preferred embodiment, the Tool, as either an applet which would run on top of a 
browser or as an application, would be downloaded from a Store Builder Server. Referring 
to FIG. 4, there is shown a distributed electronic commerce system 400 with a Store Builder 
Server 402. The merchant would download the Java wizard applet to build the pages for 
the Web storefront, which will reside on the Store Server 204. The Store Builder Server 
402 would also contain Java servlets that would receive the HTML from the wizard applet 
for the storefront pages that the merchant designed and would build the store pages from 
this HTML. This, of course, would happen when the merchant initially designed the pages, 
or whenever the merchant updated or modified them. The servlet, on the Store Builder 
Server 402, would then publish the Web storefront pages wherever the merchant designates. 
The commerce system is thereby distributed even more, by separating (if desired) the tasks 
associated with designing the merchant's Web site. In alternate embodiments, the Tool 
could be downloaded from the Transaction Server 206 or obtained on a CD ROM or other 
recordable medium. 
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2. Detailed Description of the Shopping Flow 

Referring to FIG. 5, flow diagram 500 illustrates the high-level functions that each of the 
servers (see FIG. 4), or each of the Web sites hosted thereon, performs in a typical shopping 
experience of a customer. 

The customer, using a browser, goes to the Store Server and begins shopping, that is, 
browsing the content of the Web storefront 502. When the customer finds a product that 
the customer would like to buy, he selects that product 504. The Store Server then jumps 
to the Store Builder Server by using a Uniform Resource Locator ("URL") 506. The URL, 
called a price URL, contains all of the relevant information on the product, and all the 
information necessary to build a "Buy Page." The relevant product information includes a 
picture of the product, the product's price, and a description of the product. 

The Store Builder Server receives the price URL, which is encrypted, and a Java "Buy 
Page" servlet builds a Buy Page from the received HTML 508. The customer can now 
either accept by selecting the option that puts the product in the customer's "shopping 
basket/' or cancel the buy 5 10. If the buy operation is cancelled, then the customer is 
returned to the Store Server and can continue shopping. If the buy operation is accepted 
the Store Builder Server then presents the customer with his entire shopping basket up to 
that point, which the Store Builder Server creates and maintains. The customer can now 
delete items from the basket, change the quantities, "purchase" the entire basket, or return 
to the Store Server to continue shopping 512. It should be clear that the previous buy 
operation was equivalent to dropping the product in the shopping basket, and the purchase 
operation is equivalent to going to the check-out counter. The Java servlet that maintains 
the shopping basket could use any of a variety of means, including without limitation 
tracking the Web customer's browser address or prompting the customer for a name, for 
keeping track of which customer belongs to which basket. 



WO 99/50771 PCT/GB98/03852 

10 

The customer leaves his shopping basket page by either making a purchase or continuing 
shopping. If the customer decides to make the purchase, he is hyperlinked to the 
Transaction Server 514. The Transaction Server, thus, is not involved until money is ready 
to be transferred. The Transaction Server, therefore, immediately establishes a secure link 
between itself and the customer's browser 516. Any security protocol could be used, but 
the secure sockets layer ("SSL") protocol is preferred. After establishing a secure link, the 
Transaction Server prompts the customer for the necessary identification, delivery, and 
payment information 518. 

In an alternate embodiment, the functions of establishing a secure link and getting the 
customer's payment information could be done in the Store Builder Server. The 
Transaction Server would then receive this information from the Store Builder Server, in an 
encrypted form, and decrypt it. This would provide an embodiment in which the 
Transaction Server did not need to interact in real-time with the customer, but merely 
provide a confirmation if desired. 

The Transaction Server may, optionally, verify the credit card information, authorise the 
payment amount, and transfer the funds to the merchant's account S20. The Transaction 
Server would do this by using a third party credit card clearinghouse such as IC Verify or 
Automated Transaction Services (ATS). The merchant need not request this service from 
the Transaction Server, however. Low-volume merchants may prefer simply to be e-mailed 
(securely) or faxed the entire purchase order, and perform these functions themselves, 
thereby saving the associated cost that the transaction service provider would have charged. 
Additionally, the merchant may prefer to check his inventory before charging the customer. 

In either case, the Transaction Server will notify the merchant of the status of the 
transaction and supply all of the product, customer, delivery, and payment information 522. 
If the customer provided an e-mail account, then the Transaction Server will also send a 
confirmation of the transaction to the customer 522. 
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The Transaction Server could also perform, in alternate embodiments, the functions of the 
Store Builder Server. In such an embodiment, the price URL would hyperlink to the 
Transaction Server which would contain the Java servlet that builds the Buy Page, and the 
Java servlet that maintains the shopping basket. 

3 . High-Level Functions Performed by each Server 

Having explained the sequence of events and communications between the servers during a 
typical transaction, it will be instructive to summarise, individually, the functions performed 
by each of the servers. 

a. Functions Performed by the Store Server 

The Web storefront performs one basic service, and that is to present the multi-media 
content to the customer in order to let the customer shop. The format of this presentation is 
controlled by the merchant, and can easily be designed using the Development Tool 
disclosed in the Development Tool Application of the applicant under IBM reference 
number BC9-98-020. 

The Web storefront could have a variety of other functions associated with it. For instance, 
background information on the merchant, contact information, news items of interest to the 
merchant's customers, etc. can all be displayed on the Web storefront. 

As discussed earlier, the merchant can control inventory and financial data in any manner 
desired. If the merchant utilises a computer-based database, then the merchant can also 
interface this to the Web storefront. This could be used to supply information on 
backorders, quantities available, current prices, etc. to the customer. In a sophisticated 
system, the database could even possibly be interfaced electronically with the Transaction 
Server by creating a program that processes the e-mail order notifications sent by the 
Transaction Server. 
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b. Functions Performed by the Store Builder Server 

The first major function of the Store Builder Server is to help the merchant get his Web 
storefront up and running. The Store Builder Server first provides the wizard applet or 
application, which allows the merchant to create his Web storefront. The Store Builder 
Server then accepts the HTML for the Web storefront from the merchant and builds the 
Web storefront. The Store Builder Server then publishes the Web storefront at a site of the 
merchant's choosing. The merchant supplies a user ID and a password to the Store Builder 
Server, and the Store Builder Server uses file transfer protocol ("FTP"), or some other 
service, to send the Web pages to the chosen hosting site. 

The second major function of the Store Builder Server is to provide the shopping basket for 
the customer. The Store Builder Server places each product in the basket as the customer 
selects or buys them and holds them until the customer is ready to check out. At that point, 
the Store Builder Server transfers control, and the relevant information, to the Transaction 
Server. 

c. Functions Performed by the Transaction Server 

The Transaction Server has only one general responsibility, and that is to process the 
customer's information. This involves getting the information from the customer and 
transferring it to the merchant. As explained earlier, it may also involve verifying the 
information, getting the purchase authorised, and transferring the funds. Additionally, the 
Transaction Server can also send the customer a confirmation of the transaction. 

Also of importance is the fact that the Transaction Server, like the Store Builder Server, 
need not know where the Store Server is located. That is, the Transaction Server does not 
require that the Store Server, or even the Store Builder Server, be at any particular Internet 
address. Even in an embodiment in which the Transaction Server also performed the 
functions of the Store Builder Server, the Transaction Server would not need to know 
where the Store Server was located. In such a case, the Transaction Server would receive 
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the price URL with the product information. It is evident, however, that once the price 
URL is sent, the location of the Store Server (or rather, the location from which the price 
URL was sent) is, and needs to be, known. Knowing where the price URL was sent from 
(typically a page from the Store Server) allows the Transaction Server or the Store Builder 
Server to hyperlink the Web customer back there to continue shopping. 

4. Advantages associated with the Preferred Embodiment 
a. Advantages for the Merchant 

The preferred embodiment has a number of significant advantages for the merchant who 
desires to participate in electronic commerce. First, it is less expensive than the 
non-distributed system. The merchant need only buy the Development Tool to create the 
Web site, pay for hosting of the Web storefront at an ISP of the merchant's choice, and pay 
the charge for the transaction services (usually based on volume). Hosting fees can be as 
low as twenty dollars per month depending on the memory and the bandwidth required. 

Second, it is much simpler to create the Web storefront than to create an. ordinary electronic 
commerce Web site. The Development Tool, which is described in the Development Tool 
Application mentioned earlier, allows the merchant to design, build, and publish a web site 
in a short period of time. It also makes it easy to modify the site. This is to be compared 
with the process of hiring a professional to do it, or with educating oneself about the 
process and doing it alone. 

Third, it offers a great deal of control to the merchant. The merchant can redesign the site, 
change prices, decide to have a sale, add or delete products, update the site with pictures or 
other content, expand the number of places that offer the products for sale on-line, change 
hosting sites, and much more, all without even notifying the Store Builder Server or the 
Transaction Server. The merchant has almost complete control. The merchant can do 
anything the merchant wants with the site or with the information on the site. The only 
restriction is that the price URLs, which allow the Store Builder Server to build the Buy 
Pages, have to be included on the site, or elsewhere, in order for the Web customer to place 
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an order. The merchant can even totally remove the Web storefront, and simply post the 
price URLs on news groups or on 
another web site. 

It should be clear that the distributed electronic commerce system offers significant 
advantages to all merchants, particularly those of small to medium size. 

b. Advantages for the Transaction Service Provider 

There are a number of distinct advantages that this embodiment offers the transaction 
service provider. First, overhead is minimised. Much of the overhead and cost of hosting a 
commerce Web site comes from the bandwidth requirement. Every time that a Web site 
gets a "hit," information must be transmitted. If the transaction service provider chooses 
not to host the Web storefronts, then it does not have to process any of the hits associated 
with all of the shopping that occurs on the Web storefronts. The bandwidth usage will be 
even lower because, presumably, many of the merchants will choose to do their own credit 
card verification, thereby eliminating those transmissions as well. Further, in embodiments 
utilising a Store Builder Server, the Transaction Server does not need to maintain the 
shopping baskets, nor process the hits associated with each of the buys. 

Second, the amount of memory required is minimised. The Transaction Server does not 
need to host any of the Web storefronts, nor does it need to maintain any shopping baskets 
nor any information on the products being offered for sale by the merchants, nor does it 
need to keep any data regarding the Store Servers. In the preferred embodiment, the 
primary merchant-related data that the Transaction Server needs to store is a list of all of 
the registered merchants and their contact information. Clearly, however, Transaction 
Servers will want to keep track of sales so that they can bill the merchant's for their 
services, and may want to store additional information and statistics about the merchants as 
well. 
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Third, the barrier to entering into electronic commerce is lowered for the merchants. This 
benefits the transaction service provider because it opens up a whole new group of potential 
customers. These potential customers are the merchants who could not afford to do 
non-distributed Web commerce. 

Fourth, the technique is also scaleable. The transaction service provider can serve a much 
larger number of merchants with a given Transaction Server (due to the advantages above). 
If the number of sales grows and a particular Transaction Server reaches its threshold in 
memory or bandwidth, then the transaction service provider can simply add another 
Transaction Server and have the Store Builder Server direct some of the traffic to it. The 
Store Builder Server is also scaleable, and if an additional server is needed due to volume it 
can be added. In that case, the provider can use the new server for future merchants or 
even direct current merchants to create any future price URLs (for new products or changes 
for existing products) using the new server. 

5 . Virtual Commerce 

It is useful to broaden some of the concepts introduced or discussed above in order to see 
how they fit into the broader concept of virtual commerce. The merchant's web site, that is 
the actual web pages, can be considered to be a virtual store. The virtual store could span 
across one or more physical servers or computers, and these servers can collectively be 
referred to as the store server system. Analogously, the transaction service provider's web 
site can be considered to be a virtual cashier, spanning across a cashier server system 
comprised of one or more servers. The store builder j server web site could be considered to 
be yet a third virtual entity, or it can more simply be considered to be either part of the 
virtual store or the virtual cashier. 

Numerous criteria could be developed to determine when these virtual entities could be 
considered to be distributed. Some such criteria include: different servers or computers 
hosting the web sites; different processors executing the instructions associated with each 
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web site, with each processor potentially accessing the same memory; or each web site 
merely responding to a different network address, possibly residing in the same memory on 
a common server, running on the same processor, and accessing the network over the same 
hardware such as a communications card. Each of these ideas is meant to be encompassed 
in the present application when referring to distributed systems. For this reason, the 
computers or servers that are part of the store server system may also form part of the 
cashier server system. 

These virtual stores and cashiers are presently displayed over the World Wide Web and the 
Internet, but future networks will surely arise for which virtual commerce will be applicable. 
Further, the present means of accessing and displaying virtual entities will change. 
Presently, web browsers running on personal computers processing HTML pages with 
HTTP requests and using URLs to link between pages is the preferred mechanism or system 
for customers to access the content. Software and computer technology will quickly 
replace many of these standards. Additionally, other technologies involving optics, 
magnetics, and other sciences could also produce viable methods of accessing and 
displaying virtual entities. Each of these potential advances, when used to enable a 
distributed commerce system over a network, can be viewed as a further embodiment of the 
present invention. 

6. General Implementation 

Distributed commerce systems, in accordance with the present invention can be, at least 
partially, implemented by hardware, software, or a combination of both. This may be done 
for example, by Java applets and servlets running on a variety of host equipment. 
Moreover, this functionality may be embodied in computer readable media such as 3.5 inch 
diskettes to be used in programming an information-processing apparatus to perform in 
accordance with the invention. This functionality may also be embodied in computer 
readable media such as a transmitted waveform to be used in transmitting the information or 
functionality. 
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Although a specific embodiment of the invention has been disclosed, it will be understood 
by those having skill in the art that changes can be made to this specific embodiment 
without departing from the scope of the invention as defined in the appended claims. 
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CLAIMS 

1 . A communications system for transacting business comprising a customer system 
(110, 1 14, 112, 1 16) for allowing a customer to make shopping requests, and a server 
system (108) which is coupled to the customer system, wherein the server system comprises 
a virtual cashier (104) for receiving product requests and payment information, and 
wherein the virtual cashier responds to a first network address; a virtual store (106), 
and wherein the virtual store responds to a second network address, the virtual store 
comprising: 

first receiving means (102) for receiving a shopping request from the customer 
system; and/or 

sending means (102) for sending a product request to the virtual cashier; and/or 
second receiving means for receiving payment information from the customer system 
characterised in that the server (108) is distributed so that at least one of the virtual cashier 
(104), the virtual store (106) and the receiving and sending means (102) is not contained in 
the server (108) but is separate from it (202, 204). 

2. The system of claim 1, wherein: 

the receiving means comprises using a hyper-text markup language ("HTML") page 
containing uniform resource locators ("URLs") attached to specific products allowing the 
customer system to select a given product and to thereby issue the corresponding URL to 
the virtual store; and the sending means comprises means for sending product information 
describing at least one product and a merchant identifier which identifies the seller of the at 
least one product. 

3. The system of claim 1 or 2, wherein the first receiving means comprises a means for 
receiving a URL containing information about a single product. 

4. The system of claim 1 or 2, wherein the first receiving means (102) comprises a 
means for receiving a list of products which a customer has selected. 



WO 99/50771 



19 



PCT/GB98/03852 



5. The system of claim 1 or 2, wherein the second receiving means comprises a means 
for securing the transmission link between the virtual cashier and the customer. 

6. A method of operating a communications system for transacting business, wherein 
the communications system comprises a customer system (110, 114, 112, 1 16) for allowing 
a customer to make shopping requests, and a server system (108) which is coupled to the 
customer system; wherein the server system comprises a virtual cashier (104) for receiving 
product requests and payment information, the virtual cashier responding to a first network 
address, and a virtual store (106) for shopping, the virtual store responding to a second 
network address; the method for transacting business including any one or more of the 
steps of: 

receiving a shopping request at the virtual store (106) from the customer system; 
and sending a product request to the virtual cashier (104) from the virtual store; receiving 
product requests at the virtual cashier from the virtual store; and/orreceiving payment 
information at the virtual cashier from the customer system; and/or sending notification of 
the transaction to the owner of the virtual store; and/or sending confirmation of the 
transaction to the customer; characterised by the step of having the server system (108) 
distributed so that at least one of the virtual cashier (104), the virtual store (106) and the 
receiving and sending steps are located in at least two servers (202,204). 

7. A computer readable medium for use in communications system for transacting 
business, wherein the communications system comprises a customer system for allowing a 
customer to make shopping requests, and a server system which is coupled to the customer 

25 system; wherein the server system comprises a virtual cashier for receiving product requests 

and payment information, the virtual cashier responding to a first network address, and a 
virtual store for shopping, the virtual store responding to a second network address; the 
computer readable medium containing program instructions for transacting business, the 
program instructions comprising instructions for: 
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receiving a shopping request at the virtual store from the customer system; and/or sending 
a product request to the virtual cashier from the virtual store; and/or receiving product 
requests at the virtual cashier from the virtual store; and/or receiving payment information 
at the virtual cashier from the customer system and/or sending notification of the transaction 
to the owner of the virtual store, and/or sending confirmation of the transaction to the 
customer. 

8. A virtual store comprising a transaction processor (102), an inventory and financial 
database (104), a web storefront (106) and a server (108); characterised in that the server 
(108) is distributed so that the processor (102), the database (104) and the storefront (106) 
are distributed between at least two servers (202,204) 

9. A virtual store comprising a transaction processor (202), a web storefront (204) and 
an inventory and financial database (104) characterised in that the transaction processor 
(102) comprises a transaction server (202) and the web storefront (106) comprises a store 
server (204). 

10. A virtual store (400) comprising a transaction processor (102) and a web storefront 
(106) and a server, characterised in that the transaction processor comprises a transaction 
server (202), the web storefront comprises a store server (204) and there is a store builder 
server (402) which in use can act as a tool whereby a user can download therefrom to build 
pages of the web storefront (106). 
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